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(54) Buffering for load balancing in on-demand video servers 



(57) A video server is provided with buffer manager 
which balances the loads on the various "movie storage" 
elements of a video server by preferentially buffering 
streams on highly loaded storage elements. The alloca- 
tion of buffer takes place only when the storage element 
toad increases due to the, arrival of a new request or 
when buffer becomes available due" to, the pausing or 
stopping of an old request. 
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Description 



BRIEF DESCRIPTION OF THE DRAWING 



CROSS REFERENCE TO RELATED APPLICATIONS 

This application is a continuation-in-part of s/n 
08/204,038 filed on March 1 , 1 994. 



FIG. 1 



is a block diagram of a vid- 
eo-on-demand system according 
to an embodiment of the present 
invention: 



BACKGROUND OF THE INVENTION 



Field of the Invention 
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FIG. 2 



shows data structures main- 
tained by the buffer manager of 
FIG. 1; 



The present invention relates to a movie (video) on 
demand systems of the type wherein multiple clients are 
serviced by video streams delivered from a central video 
server. 

Related Art 

With the advent of digital video technology, it is fea- 
sible to provide video-on-demand services to a large 
number of clients over a geographically distributed net- 
work. The videos are stored on secondary storage de- 
vices (such as disks and tapes) on the server and deliv- 
ered to the clients. Because of non-uniform demand for 
different movies, load imbalances amongst the second- 
ary storage devices may occur. In such situations, the 
most heavily loaded secondary storage device can be- 
come a bottleneck. 

One solution to the load balancing problem is to stat- 
ically replicate popular movies on multiple secondary 
storage devices based on the expected load, such that 
the total demand for the movie can be spread among the 
devices having a copy of the movie. This is, however, 
expensive in terms of the storage space required. Addi- 
tionally, it is difficult to determine exactly how much rep- 
lication is required for any particular movie since, typi- 
cally, the demand can not be exactly forecast. Static rep- 
lication is also not well suited to dealing with the problem 
of time-varying load since the number of replicas needed 
may vary. 

Dynamic replication is more effective on load surges 
that occur on a time scale comparable to the time to copy 
a video file or segment. In dynamic replication, movies 
or portions of movies are copied, as a function of present 
demand, from heavily loaded storage devices to more 
lightly loaded storage devices in order to reduce the load. 
The effectiveness of dynamic replication in dealing with 
sudden load surges is limited by the bandwidth of the 
secondary storage devices. 

SUMMARY OF THE INVENTION 

In light of the above, the inventors have provided a 
buffer manager that balances the loads across the server 
disks by using information about load imbalances in or- 
der to decide which streams to buffer. 



is 



FIGs 3A - 3B are a flow chart of the handling of 

a start or resume request by the 
buffer manager of FIG. 1; 

FIGs. 4A - 4B are a flow chart of moving a can- 

didate stream by the buffer man- 
ager of FIG. 1 ; 



20 FIG. 5 is a flow chart of the actions taken 

by the buffer manager of FIG. 1 
on receipt of a stop request; 
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FIG. 6 is a flow chart of the steps taken 

by the buffer manager of FIG. 1 
to find buffered streams when 
new buffer becomes available; 
and, 



30 FIGs. 7A - 7B 



show, respectively, the interac- 
tions between the disk I/O proc- 
ess and the communication proc- 
ess with the buffer manager of 
FIG. 1. 



FIG. 8 is a block diagram of a system 

having a distribution node cou- 
pled to multiple server nodes by 
way of communication network. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

Overview 

In accordance with an embodiment of the present 
invention, a buffer manager balances the loads on the 
various "movie storage" disks of a video server by pref- 
erentially buffering streams on highly loaded disks or oth- 
er secondary storage devices. It should be understood, 
that while the present embodiment is described with re- 
spect to balancing the load across disks, the principles 
of the present invention are also applicable to balancing 
the load across other storage devices (such as tapes and 
jukeboxes) and across video servers. The allocation of 
buffer takes place only when the disk load increases due 
to the arrival of a new request or when buffer becomes 
available due to the pausing or stopping of an old re- 
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quest. 

The amount of memory buffer required to enable a 
following stream to read the data from its preceding 
stream is a function of the time interval between the two 
streams and the compression method used. An estimate s 
of the required buffer space can be obtained at the time 
when a new stream is created to form a new pair of con- 
secutive streams. 

The present buffer manager balances the load 
across the server disks by using information about toad 
imbalances in order to decide which streams to buffer 
At the time when a stream starts or restarts, it forms a 
consecutive pair with the stream for the same movie that 
is just ahead of it, if any. For any consecutive pair, the 
blocks brought in by the previous stream of the pair can 
be buffered so that the following stream reads them Irom 
buffer instead of disk. Therefore, the buffer requirement 
for the following stream of a consecutive pair is the 
amount of buffer required to store the required blocks 

For each disk, the buffer manager maintains a list ci 
streams currently reading from that disk, in ascendmy 
order of buffer requirement. Note that if the movie is rep- 
licated, the preceding stream of the pair could be reading 
from a different disk than the succeeding stream in the 
pair. 

One objective of the load balancing performed by 
the buffer manager is to reduce the load imbalance 
across disks. When a new stream creates a load imbal- 
ance on a disk, the buffer manager attempts to redum 
the load of the highly loaded disk by switching a stream 
of that disk to the buffer. Load imbalance is said to exist 
if the difference between the load on the highly loaded 
disk and the average load per disk exceeds a thresholc 
The stream with the lowest buffer requirement and still 
being served from that disk is selected. If sufficient buffer 
is not available, the buffer manager attempts to buffer 
the selected stream from the highly loaded disks by stop- 
ping the buffering of streams from the lightly loaded disks 
until enough buffer is available. 

The objective of the load balancing function of the 
buffer manager changes from load balancing to minimi/ 
ing the loss if the total load on the server is greater than 
the total server disk bandwidth. In this case, the streams 
with the lowest buffer requirement across all disks lot 
which the load exceeds their corresponding bandwidtn 
capacity are chosen. Once the load on a particular dis* 
falls below the maximum bandwidth of the disk, furthcf 
streams on that disk are not considered for buffering 

The present buffer manager load balancing melliud 
can be used together with a method of dynamic repiioi 
tion to provide an integrated approach to dynamic rcpt» 
cation and buffering in a video server. Buffering and o\ 
namic replication algorithms have additional charade* 
istics that are complementary and hence, make thom 
suitable to different scenarios with respect to load suro 
es. 

Dynamic replication is most effective on load surgo*. 
that occur on a time scale comparable to the time to cop/ 
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a video file or segment. The present buffer manager, on 
the other hand, can handle sudden load surges. The in- 
tegrated method thus can handle both sudden and slow 
load imbalances. 

Detailed Description 

Fig. 1 is a block diagram of a video-on-demand sys- 
tem according to an embodiment of the present inven- 
tion It is assumed that clients 10 make requests from a 
video server 30 via a communication network 20. Clients 
can submit start and stop requests. The communication 
network 20 can be, for example, and Asynchronous 
Transfer Mode (ATM) network comprising optical fiber 
cables. 

! he video server 30 is embodied within the frame- 
work ol a general purpose computer such as an RISC 
SYSTEM/6000 workstation or an ES/9000 mainframe 
(both available from International Business Machines 
Corporation of Armonk, New York). As pertains to the 
:i i iUjOii nent of the present invention, the video server 
*>ci;-de5 a buffer storage 35 which is instantiated in the 
vocd servers conventional semiconductor memory (not 
irown) ,-ind a number of processes 50, 60, and 80 which 
cmccuic under control of the video servers operating sys- 
iom or mam control program (not shown). 

Movies (also referred to as video data) are stored in 
* number of disks 55 and/or other mass storage devices 
rv<iirvttod storing movies (generally referred to as sec- 
mc-i-try storage) which are connected to the video server. 
T r>c disks 55 can be, for example, in the form of a DASD 
nfr^y or RAID system. Other disks (not shown) store 
wo* Ktng data and program code for the video server 30. 
T no proqram code includes processes such as the serv- 
of, rrvitn control program, a movie scheduling program, 
n customer usage tracking program, and the various 
communications, I/O and buffer management process- 
or 

The buffer storage 35 is subdivided into two pools - 
«i ?r e*? pool 70 that contains free blocks that can be used 
io* p»e storage of data and a buffer pool 40 that has 
t> containing data ready for transmission to the us- 
v \ t ho disk I/O process 50 reads video data from the 
o>%*.'. S5 into empty buffers obtained from the free pool 
^kj inserts the buffers into the buffer pool 40. The 
; .f^Hjnc-iiion process 60 transmits video data from the 
: • r i>* {xoi 40 or disks 55 to the clients 1 0. The load bal- 
* • k; outior manager 80 allocates buffers to streams 
v ■+ . u. nduce the load imbalance across the disks or 
r-n.r^u/e men umber of streams being served from buff- 
r*. ;v i vndng of the current load on the system. Those 

* j. the art will recognize that the disks 10 are cou- 
; * . tr»c video server by way of a controller (not shown) 

,-isc includes its own internal memory buffer, 
video data that has been read into the buffer for 

• ». cm be retained for re-transmission to other cli- 
.w!s "hi* conserves server resources since the 
*.• i« * emitted block does not have to be re-read from 
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disk 55. Hence the buffer manager 80 selects a set of 
clients whose blocks will be retained in the buffer for sub- 
sequent re-transmission to other clients. Clients receiv- 
ing re-transmitted blocks will be referred to as buffered 
clients. 

A number of data structures are maintained by the 
buffer manager 80. These structures, shown in FIG. 2, 
include a stream table 110, a movie table 150, a disk ta- 
ble 1 75, a nominal free space counter 185 and an actual 
free space counter 190. 

The stream table 110 contains one stream entry for 
each movie stream currently active. Each stream entry 
includes a number of fields 120-145. These fields con- 
tain, respectively, the identifier of the stream (Stream Id 
120), the movie identifier (Movie Id 125), the identity of 
the disk (if any) the stream is reading from (Disk Id 127), 
the current block being displayed to the client or clients 
(current block 1 30), a read state (Read State 1 35) which 
identifies the source of the video data being provided to 
the clients, an indicator for the amount of buffer neces- 
sary to service the stream from the buffer pool (Buffer 
Reqd. 140), and a mark (Mark 145) indicating whether 
the source of the stream is moveable to a disk from the 
buffer. 

The read state 135 can take on 4 values - DISK if 
the stream is reading from disk, BUFFER if the stream 
is a buffered stream, DISK_TO_BUFFER if the stream 
is in the process of being switched from the disk to the 
buffer and BUFFER_TO_DISK if the stream is in the 
process of being switched from the buffer to disk. 

The mark field {mark 1 45) is used by the buffer man- 
ager when allocating buffer and can take on four values 
- blank, MOVEABLE if the stream can be switched from 
buffer to disk and UNMOVABLE if it cannot and CANDI- 
DATE if the buffer manager is trying to switch the stream 
to the buffer. 

The movie table 150 contains the movie id (Movie 
Id 155) and movie list for each active movie. The movie 
list is a list of stream elements (170) for that movie in 
ascending order of current block. The movie table in- 
cludes a pointer to the first and last elements of the list 
(First str 160 and Last str. 165, respectively). Each 
stream element includes the identifier of the stream (Str. 
Id 167) and a pointer to the next stream element (Next 
169). 

The disk table 175 keeps track of the load on the 
disks 55. For each disk, the disk table contains the iden- 
tifier of the disk (disk id 178) the actual load on the disk 
(180)andthe potential load (1 82). The potential load rep- 
resents the number of streams that can be switched to 
this disk in order to free buffer for reducing the load on 
another disk. It is used by the buffer manager 80 when 
allocating buffer to the disk. 

The two counters - the nominal free space 185 and 
the actual free space 190 are used to keep track of the 
amount of buffer space available in the free pool 70. The 
actual free space counter 1 90 is initialized to the total 
amount of buffer available. The actual free space counter 
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is used to keep track of the actual amount of buffer avail- 
able in the free pool 70. 

The nominal free space counter is initialized to some 
high fraction (such as 90%) of the total buffer space avail- 
s able. The nominal free space counter is used by the buff- 
er manager 80 when allocating and deallocating space; 
i.e. when allocating buffer space, the buffer manager al- 
locates only the amount of space specified by the nom- 
inal free space counter. This is because fluctuations in 
compression ratios may cause the actual amount of buff- 
er required by a stream to vary. Hence, at times a stream 
may require more or less buffer space than allocated to 
it by the buffer manager. The difference between the in- 
itial values of the nominal and actual free space counters 
(10% in the example) is a safety buffer used for accom- 
modating this variation. v 

A flow chart o^^he^r^^lingpf restart request by the ' 
buffer manager is sho^^l^g^^A^B'After a new re- 
quest arrives in step 210, in step 220 the buffer manager 
creates a new stream entry for the request and inserts 
the new stream entry into the stream table 1 1 0. The read 
state of the stream entry is set to Dl SK. The current block 
1 30 is set to the requested block and the stream entry is 
inserted into the movie list for the movie using the current 
block to determine its position. 

In step 230, the buffer manager scans the movie list 
170 to determine the closest preceding stream if any for 
the movie; i.e. the stream among all the streams reading 
this movie whose current block is closest to the current 
block of this request. If no such block exists, in step 240 
buffer manager exits the new request handling process. 
If such a request exists, in step 250 the buffer manager 
sets the buffer reqd. field 140 in the stream entry to the 
amount of storage required to buffer all the blocks be- 
tween the immediately preceding stream and the current 
request. In step 255 the buffer manager 80 determines 
the buffering mode. If the loads on all disks are greater 
than their corresponding load threshold, the buffer man- 
ager switches to the mode of maximizing the number of 
streams being served from the buffer. This can be ac- 
complished as shown, for example in United States Pat- 
ent Application s/n 08/204,038 filed on March 1, 1994, 
which is incorporated by reference herein as if printed in 
full below. Otherwise, the buffer manager selects a disk 
(1rom among the disks 55) from which to service this re- 
quest and updates the load on the selected disk in step 
260. 

Next, in step 270, the buffer manager determines if 
the load on the selected disk is above a pre -specified 
threshold. If not, in step 280 buffer manager exits the new 
request handling process. If the load is above the thresh- 
old, in step 290-the buffer manager examines the stream 
table 110 to find the stream that is being serviced from 
the disk (read state 135 equal to BUFFER or 
BUFFER_TO_DISK) that has the lowest buffer require- 
ment 1 40 and sets the mark field 1 45 of the stream entry 
for that particular stream to CANDIDATE. Then, in step 
295 the buffer manager invokes the "Move candidate 
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stream" procedure of Figs. 4A and 4B and exits the new 
request handling process. 

Figs. 4A and 4B describe the buffer manager's 
"Move candidate stream" procedure. In step 300 the 
buffer manager examines the available space to deter- 
mine if enough free buffer space exists to accommodate 
the candidate request. The available space is the nomi- 
nal free space 1 85 together with the space held by move- 
able streams (streams with mark 145 equal to MOVE- 
ABLE). In the first pass through the loop, there will not 
be any such streams. If enough buffer space is available, 
the buffer manager initiates steps 370-410 to buffer the 
request. 

If enough free buffer is not available, the buffer man- 
ager attempts to free some space by displacing some 
other stream. First, in step 310, the buffer manager 
checks if there are any more unmarked streams. If there 
are none, no additional buffer can be freed, hence the 
buffer manager unmarks all the stream entries and re- 
sets the disk potential loads in step 31 5 and, in step 320 
returns failure to the invoking process. If there are un- 
marked streams, in step 330 the buffer manager locates 
the unmarked stream with the largest buffer reqd 1 40. 
Then, in step 340, the buffer manager determines wheth- 
er this stream can be moved to the disk and its buffer 
freed. The unmarked stream can be moved if moving the 
stream to disk does not cause the projected load on the 
unmarked stream's disk to exceed the projected load on 
the candidate stream's disk. 

The projected load on the unmarked stream's disk 
is the sum of the actual load 180, the potential load 182 
and the load imposed by the unmarked stream. The pro- 
jected load on the candidate stream's disk is the actual 
load 180 minus the load of the candidate stream. If the 
unmarked stream cannot be moved, in step 360 its mark 
field 145 is set to UNMOVABLE. If it can be moved, in 
step 350 its mark field 1 45 is set to MOVEABLE and the 
potential load field 182 of the unmarked stream's disk is 
incremented by the load of the unmarked stream. In ei- 
ther case, the buffer manager then loops back to step 
300. 

If, in step 300, it is determined that the available 
space is greater than the buffer requirement of the can- 
didate stream (i.e. the candidate stream can be moved), 
the buffer manager executes step 370. In step 370, the 
buffer of all streams marked moveable are released by 
incrementing the nominal free space counter 1 85 by buff- 
er reqd field 140 of the stream. Then, in step 380, the 
sources of the streams are moved to disks by setting the 
read state 1 35 of the streams to DISK. In step 390, the 
nominal free space counter 185 is decremented by the 
buffer reqd. field 140 of the candidate stream and the 
read state 135 of the candidate streams is set to 
DISK_TO_BUFFER, effectively allocating buffer to the 
candidate stream. Finally, in step 400, the actual load 
1 80 of the disks are updated to reflect the new loads on 
the disks and the potential load fields 1 82 of the disks 
are reset to 0 and the mark field 1 45 of the is set to blank. 
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The buffer manager then returns success the invoking 
process in step 410. 

The actions taken by the buffer manager on receipt 
of a "stop" request from a client are shown in Fig. 5. A 
5 stop request is a request from a client to terminate show- 
ing of the movie, in step 520, Lhe siream entry for the 
stream is removed from the stream table 110 and the 
movie list in the movie table 150 In step 530, the buffer 
manager determines if the stream had allocated buffer 
by examining its read state 135 (BUFFER or 
DISK_TO_BUFFER). If not, the buffer manager exits the 
stop request handling procedure in step 540. If the 
stream had allocated buffer, in step 550 the buffer man- 
ager frees the buffer by incrementing the nominal free 
space counter 185 by the buffer reqd. 140. In step 555 
the buffer manager determines the buffering mode (ei- 
ther load balancing or maximizing the number of streams 
served from the buffer). If the loads on all disks are still 
greater than their corresponding load threshold, then 
buffer manager goes into (or stays in, as the case may 
be) the mode of maximizing the number of streams being 
served from the buffer. Otherwise, the buffer manager 
then executes the "Look for new buffered stream" steps 
shown in Fig. 6. It should be understood that the princi- 
ples of present load balancing buffer manager can also 
be applied to client "pause" requests. 

Fig. 6 shows the steps taken by the buffer manager 
to find non-buffered streams to buffer when new buffer 
becomes available. In step 610, the buffer manager 
makes a list of disks whose actual load is above a pre- 
determined load imbalance threshold. The load imbal- 
ance threshold can be specified by the system adminis- 
trator or determined by a load balancing process execut- 
ing on the system. Then, in step 620, the buffer manager 
starts a loop over the disks in the list in descending order 
of load. For the selected disk, the buffer manager finds 
the stream with the lowest buffer requirement and marks 
this stream (mark field 145) as a candidate stream. It 
then executes the "Move candidate stream" procedure 
(of FIG. 4) in step 640. When the move candidate pro- 
cedure has been completed, in step 650 the buffer man- 
ager then checks to see if the loop is complete and if so, 
exits the "Look for new stream to buffer" procedure in 
step 660. Otherwise, the buffer manager selects the next 
disk in step 670 and then re- executes the loop starting 
again at step 630. 

Figs 7A and 7B shows the interactions between the 
disk I/O process 50, the communication process 60 and 
the toad balancing buffer manager 80. In step 710, the 
disk I/O process 50 receives a request from a client to 
read a block from the disk. Before initiating an I/O oper- 
ation to read a requested block, in step 720 the disk I/O 
process 50 looks in the buffer pool in step 720 to deter- 
mine* if the requested block has been read in. If it has, in 
step 723 the disk I/O process checks the read state of 
the stream to see if it is DISK_TO_BUFFER. If it is not, 
the disk I/O process exits in step 730. If it is 
DISK_TO_BUFFER. in step 726 the disk I/O process 
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changes the read state to BUFFER and then exits in step 
730. If not, in step 740 the disk I/O process gets a free 
buffer from the free pool, decrements the actual free 
space counter starts the I/O and then exits in step 750. 

After.transmitting a block, the communication proc- 
ess 60 checks the read state of the following stream in 
step 760. If the read state is BUFFER or 
DISK_TO_BUFFER, the communications process exits 
in step 770. Otherwise, in step 765 the communication 
process increments the actual free space counter 1 90 
and returns the block to the free pool 70. 

FIG. 8 is a block diagram of a system having a dis- 
tribution node coupled to multiple server nodes by way 
of communication network. In this embodiment the dis- 
tribution node includes the load balancing buffer manag- 
er which balances the load across the video servers m 
accordance with the foregoing principles. 

Now that the invention has been described by way 
of the preferred embodiment, various modifications and 
improvements will occur to those of skill in the art. Thus 
it should be understood that the preferred embodiment 
has been provided as an example and not as a limitatior 
The scope of the invention is defined by the appended 
claims. 



Claims 

1. A method of managing memory buffer in a vidr>r> 
server, wherein a plurality of clients are served from 
video streams provided from disks, comprising the 
steps of: 

determining buffer requirements of a plurality of the 
video streams, the buffer requirements being h 
number of frames separating each video stream 
from an immediately previous video stream carrying 
the same video; 

creating a list of streams being served from each 
of-the disks, ordered by the buffer requirement cl 
each of the streams; 

determining when to balance the load across the 
disks; 

allocating the buffer to the streams on a most heavir/ 
loaded one of the disks so as to serve the streams 
from the buffer, starting from a stream with a small 
est buffer requirement and proceeding to streams 
with larger buffer requirements until the build 
requirement of a stream can not be satisfied; and 
retaining blocks of the immediately preceding 
stream in the buffer allocated to its following stream 
and discarding the blocks from the buffer as they we 
read by a client viewing the following stream. 

2. The method of Claim 1 comprising the further stop; 
of: 

updating the list when any of starting, stopping 
pausing and resuming of a video occurs; and, 
responsive to the updating, identifying the most 



to 
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heavily loaded one of the disks after the updating 
and reallocating the buffer to the streams being 
served from the most heavily loaded disk, starling 
from a stream with a smallest buffer requirement and 
proceeding to streams with larger buffer require- 
ments until the buffer requirement of a stream can 
not be satisfied. 

A method of managing memory buffer in a video 
server, wherein a plurality of clients are served from 
video streams provided from disks, comprising the 
step of: 

determining buffer requirements of a plurality of the 
video streams, the buffer requirements being a 
number of frames separating each video stream 
Irom an immediately previous video stream carrying 
the same video; . 

creating a list of streams being served from each of 
the disks, ordered by the buffer requirement of each 
of trie streams; 

>ci jcting a buffering mode from one of (a) balancing 
the load across the disks and (b) maximizing 
streams that can be served from the buffer; 
when the mode is balancing the load across the 
dto^s allocating the buffer to the streams on a most 
hoivily loaded one of the disks so as to serve the 
streams from the buffer, starting from a stream with 
h smallest buffer requirement and proceeding to 
Mfonms with larger buffer requirements until the 
buffer requirement of a stream can not be satisfied; 
rind 

when the mode is maximizing the streams that can 
be served from the buffer: examining the buffer 
rccuirements and as a function thereof, allocating 
the buffer so as to maximize a number of streams 
tr^t can be provided therefrom regardless of the 
lond distribution across the disks. 

A system for managing memory buffer in a video 
server wherein a plurality of clients are served from 
v»doo streams provided from disks, comprising: 
rnotns for determining buffer requirements of a plu- 
mmy of the video streams, the buffer requirements 
t>o«nq a number of frames separating each video 
urfcam irom an immediately previous video stream 
c^frymg the same video; 

r>i,ms lor creating a list of streams being served 
»» ,jm urtch of the disks, ordered by the buffer require- 

ot each of the streams; 
'^ns for determining when to balance the load 
^ roi>s the disks; 

r-^c mi for allocating the buffer to the streams on a 
heavily loaded one of the disks so as to serve 
(**o st roams from the buffer, starting from a stream 
* smallest buffer requirement and proceeding 
* Mfcnms with larger buffer requirements until the 
?-»?ir*r requirement of a stream can not be satisfied; 
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means for retaining blocks of the immediately pre- 
ceding stream in the buffer allocated to its following 
stream and discarding the blocks from the buffer as 
they are read by a client viewing the following 
stream. s 

A method of managing memory buffer in a video 
server, wherein a plurality of clients are served from 
video streams provided by video storage elements, 
comprising the steps of: 10 
determining buffer requirements of a plurality ol the 
video streams, the buffer requirements being a 
number of frames separating each video stream 
from an immediately previous video stream carrying 
the same video; 75 
creating a list of streams being served from each of 
the storage elements, ordered by the buffer require- 
ment of each of the streams; 
allocating the buffer to the streams on a most heavily 
loaded one of the storage elements so as to serve 20 
the streams from the buffer, starting from a stream 
with a smallest buffer requirement and proceeding 
to streams with larger buffer requirements until the 
buffer requirement of a stream can not be satisfied; 
and, 25 
retaining blocks of the immediately preceding 
stream in the buffer allocated to its following stream 
and discarding the blocks from the buffer as they are 
read by a client viewing the following stream. 

30 

The method of Claim 6 comprising the further steps 
of: 

updating the list when any of starting, stopping, 
pausing and resuming of a video occurs; and, 
responsive to the updating, identifying the most 35 
heavily loaded one of the disks after the updating 
and reallocating the buffer to the streams being 
served from the most heavily loaded disk, starting 
from a stream with a smallest buffer requirement and 
proceeding to streams with larger buffer require- 40 
ments until the buffer requirement of a stream can 
not be satisfied. 



45 



so 
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FIG. 5 
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FIG. 7 A 
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FIG. 7B 
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